Method and system for risk determination of a route

ABSTRACT

A method for risk determination of a route includes collecting a set of inputs and determining a set of risk scores. Additionally, the method can include any or all of: processing the set of inputs; organizing the set of inputs; determining a model based on the set of inputs; determining a set of risk scores; producing an outputs based on the set of risk scores; and/or any other suitable processes.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. application Ser. No.17/111,299, filed 3 Dec. 2020, which claims the benefit of U.S.Provisional Application No. 62/942,907, filed 3 Dec. 2019, and U.S.Provisional Application No. 63/051,593, filed 14 Jul. 2020, each whichis incorporated in its entirety by this reference.

TECHNICAL FIELD

This invention relates generally to the vehicle telematics field, andmore specifically to a new and useful method and system for determiningthe risk associated with a route in the vehicle telematics field.

BACKGROUND

Vehicular collisions are accountable for a significant number of deathsper year, and a high percentage of these collisions can be attributed tothe driver's behavior, and also be highly dependent on the particularroute that the driver is traversing. While conventional systems andmethods can assess and recommend routes to users based on time todestination and/or distance alone, these factors do not reflect the mostfavorable routes for a user to drive in terms of safety and/or otherimportant factors.

Thus, there is a need in the vehicle telematics field to create a newand useful method and system for identifying and recommending routes tominimize the driver's risk of collision.

BRIEF DESCRIPTION OF THE FIGURES

FIG. 1 is a schematic of the method 100 for risk determination of aroute.

FIG. 2 depicts a variation of the route segments making up each of a setof routes.

FIGS. 3A-3F depict a variation of the organization and aggregation ofdata associated with a set of routes traveled by a set of drivers.

FIG. 4 depicts a schematic of sensor data, events, and outputs of avariation of the method 100.

FIG. 5 depicts a variation of a driver score visualization provided asan output in variations of the method 100.

FIG. 6 depicts a variation of a route risk visualization provided as anoutput in variations of the method 100.

FIG. 7 depicts a schematic variation of a set of inputs used indetermining a model for route risk determination.

FIG. 8 depicts a variation of a set of inputs involved in the method100.

DESCRIPTION OF THE PREFERRED EMBODIMENTS

The following description of the preferred embodiments of the inventionis not intended to limit the invention to these preferred embodiments,but rather to enable any person skilled in the art to make and use thisinvention.

1. Overview

As shown in FIG. 1, the method 100 for risk determination of a routeincludes collecting a set of inputs S110 and determining a set of riskscores S140. Additionally, the method 100 can include any or all of:processing the set of inputs S120; organizing the set of inputs S125;determining a model based on the set of inputs S130; determining a setof risk scores 140; producing an outputs based on the set of risk scoresS150; and/or any other suitable processes.

Further additionally or alternatively, the method 100 can include any orall of the methods, processes, embodiments, and/or examples described inany or all of: U.S. application Ser. No. 14/566,406, filed 10 Dec. 2014,now issued as U.S. Pat. No. 9,996,811; U.S. application Ser. No.15/243,513, filed 22 Aug. 2016, now issued as U.S. Pat. No. 9,733,089;U.S. application Ser. No. 15/243,565, filed 22 Aug. 2016, now issued asU.S. Pat. No. 9,818,239; U.S. application Ser. No. 15/702,601, filed 12Sep. 2017, now issued as U.S. Pat. No. 9,955,319; U.S. application Ser.No. 15/835,284, filed 7 Dec. 2017; U.S. application Ser. No. 15/401,761,filed 9 Jan. 2017, now issued as U.S. Pat. No. 10,154,382, U.S.application Ser. No. 16/022,120, filed 28 Jun. 2018, U.S. applicationSer. No. 16/022,184, filed 28 Jun. 2018, now issued as U.S. Pat. No.10,304,329; U.S. application Ser. No. 16/166,895, filed 22 Oct. 2018,now issued as U.S. Pat. No. 10,559,196; and U.S. application Ser. No.16/201,955, filed 27 Nov. 2018, now issued as U.S. Pat. No. 10,278,039;each of which is incorporated herein in its entirety by this reference

The method 100 is preferably performed with a system as described below,but can additionally or alternatively be performed with any othersuitable system(s). Further additionally or alternatively, the method100 can be performed with any or all of the systems, components,embodiments, and/or examples described in any or all of: theapplications described above.

2. Benefits

The method and system can confer several benefits over current systemsand methods.

In a first set of variations, the method and/or system confers thebenefit of a risk associated with a route and/or route segment based onnumerous factors (e.g., human driving behavior, temporal considerations,road infrastructure, etc.), which can in turn be used for multipledifferent applications, such as in helping drivers make more informednavigation choices. In specific examples, for instance, the methodenables drivers to take into account factors beyond time of arrival anddistance, such as route safety (e.g., based on predicted risk ofcollision), when choosing a route to traverse.

In a second set of variations, additional or alternative to thosedescribed above, the method and/or system confers the benefit ofassessing and/or informing road infrastructure safety. In specificexamples, for instance, the risk associated with various features ofand/or changes to road infrastructure (e.g., left turn light added to anintersection, 4-way stop changed to a roundabout, etc.) can bedetermined. In specific examples, this information can be used in any orall of the following: predicting the effect of an infrastructure changeprior to implementing it; recommending a change in infrastructure toofficials (e.g., city planning officials, civil engineers, etc.);reporting an infrastructure feature associated with a high risk ofcollision; and/or produce any other suitable outcome(s).

In a third set of variations, additional or alternative to thosedescribed above, the method and/or system confers the benefit ofleveraging continuously collected data associated with a set of drivers(e.g., aggregated set of drivers, multiple drivers, thousands ofdrivers, tens of thousands of drivers, etc.), along with locationinformation, to determine and attribute a risk factor to routes in oneor more regions and/or throughout the United States and/or within aglobal framework. In specific examples, different behaviors of driverscollected using telematic data can be used in combination with collisioninformation from one or more databases to determine a model which canaccurately quantify and/or predict the risk for a collision at variousdifferent locations and/or routes. Additionally or alternatively, thistelematic data can be used to update the model.

In specific examples, the method is designed to work with incompleteinformation associated with the set of drivers, such as incomplete GPStraces of the route driven by the driver, wherein a subset or all of theroute segments driven by the user can be determined (e.g., with a map,with driver input, based on previous routes taken by the driver, basedon routes from an aggregated set of users, etc.).

In additional or alternative specific examples, the telematic data usedto determine the driver behaviors is collected entirely from a mobiledevice or a supplementary device (e.g., computing device) arrangedwithin and/or retrofitted to the vehicle, wherein, no information istaken from sensors within the vehicle (e.g., OEM sensors) and/or addedto the vehicle in the context of an autonomous vehicle.

In a fourth set of variations, additional or alternative to thosedescribed above, the method and/or system confers the benefit of betterinforming human drivers on the risk associated with any or all of:routes they have taken (e.g., which routes commonly taken by the driverare the riskiest), routes they are currently taking (e.g., todynamically adjust the route in a navigation application, to send anotification to the driver, etc.), and/or routes they may take (e.g., toenable the driver to select one from a set of multiple routes based onthe risk score). Additionally or alternatively, any of these benefitscan be applied to mitigate risk associated with operation of anautonomous vehicle.

In a fifth set of variations, additional or alternative to thosedescribed above, the method and/or system enables the risk determinedfor routes, route segments, and/or regions to be used in determining oneor more outputs for an insurance company, such as an insurance rateand/or insurance rate adjustment based on any or all of: a region inwhich the driver lives; a common set of routes driven by the driver; theparticular driver's behavior relative to the risk of the route; and/orany other suitable information.

Additionally or alternatively, the method and/or system can confer anyother suitable benefits.

3. System

The system for route risk determination preferably functions todetermine the risk associated with one or more routes and/or routesegments. Additionally or alternatively, the system can function todetermine the model with which the route risk is determined, produce oneor more outputs based on the route risk, perform any or all of theprocesses of the method 100, and/or perform any other suitablefunctions. Additionally or alternatively, the method 100 can beperformed with any other suitable system(s).

The system for risk determination of a route preferably includes a model(e.g., as described below), wherein the model functions to determine arisk score associated with each of a set of route segments. Additionallyor alternatively, the model can function to determine any other suitableoutputs, and/or the system can include any other suitable components.

The system can include one or more client applications, such as thoseexecuting on a user device, which can function to collect informationwith which to determine one or more scores as described below, processthe information, display or otherwise present an output to a user,and/or perform any other suitable function(s). In preferred variations,for instance, the system includes and/or interfaces with a clientapplication executing on a user device (e.g., mobile device, stationarydevice, supplementary device, 3^(rd) party hardware device such as thatplaced in a vehicle by an insurance company and/or other entity, etc.)and/or any other suitable components.

The client application can optionally include and/or be in communicationwith other client applications and/or client application features on auser device (e.g., a navigation client application, a weather clientapplication, a clock client application, etc.). Additionally oralternatively, the client application can operate in absence ofcommunication with other client applications.

The client application is preferably a telematics application, whichfunctions to receive information from one or more sensors (e.g., asdescribed in S110), such as those in a user device, but can additionallyor alternatively include any other suitable client applicationsconfigured to collect information from any sensor systems (e.g., vehiclesensors such as OEM sensors, radar and/or lidar sensors and/or camerasof an autonomous vehicle, etc.)

The system can optionally include and/or be configured to interface witha user device (e.g., mobile device). The user device can include any orall of: a mobile device (e.g., cell phone, tablet, etc.), a personaluser device (e.g., driver's user device, passenger's user device, etc.),a supplementary device (e.g., a 3^(rd) party hardware device, etc.),and/or any other suitable devices and/or combination of devices.Examples of the user device include a tablet, smartphone, mobile phone,laptop, watch, wearable device (e.g., glasses), or any other suitableuser device. The user device can include any or all of: power storage(e.g., a battery), processing systems (e.g., CPU, GPU, memory, etc.),user outputs (e.g., display, speaker, vibration mechanism, etc.), userinputs (e.g., a keyboard, touchscreen, microphone, etc.), a locationsystem (e.g., a GPS system), sensors (e.g., optical sensors, such aslight sensors and cameras, orientation sensors, such as accelerometers,gyroscopes, and altimeters, audio sensors such as microphones,magnetometers, gravitational sensors, etc.), data communication system(e.g., a WiFi transceiver(s), Bluetooth transceiver(s), cellulartransceiver(s), etc.), or any other suitable component.

Additionally or alternatively, a supplementary device can be differentfrom and/or separate from other user devices (e.g., wherein the userdevice is owned by the driver and/or passenger and wherein thesupplementary device is owned by a 3^(rd) party entity such as aninsurance company and/or private company and/or public company, etc.),and/or the system can include and/or interface with any other suitabledevices.

The system can optionally include and/or be configured to interface witha sensor system (e.g., as part of a user device, separate from a userdevice, as part of a supplementary device, separate from a supplementarydevice, as part of the vehicle such as an OEM sensor system, etc.),which can include any or all of: motion sensors (e.g., accelerometer,gyroscope, magnetometer, orientation sensor, etc.), which can functionto detect any or all of: user device movement, user device orientation,vehicle movement, vehicle orientation, position of user device withinthe vehicle, and/or any other suitable information; proximity sensors(e.g., optical sensors, capacitive sensors, etc.), which can function todetect and/or classify a user's handling of a user device; locationsensors (e.g., GPS); any or all of the sensors described above; any orall of the sensors described below; and/or any other suitable sensors.In preferred variations, the set of sensors includes any or all of: aGPS sensor, an accelerometer, a gyroscope, a magnetometer, and a gravitysensor. Additionally or alternatively, the sensor system can include anyother suitable sensors.

In a first set of variations, the system includes a set of sensorsonboard a user device (e.g., placed within the vehicle, coupled to thevehicle, secured to an interior surface of the vehicle, secured to anexterior surface of the vehicle, etc.), wherein the sensors onboard theuser device are used to collect inputs (e.g., as described in S110) withwhich to determine a set of driving events associated with a driver ofthe vehicle and/or the vehicle (e.g., an autonomous vehicle).Additionally or alternatively, inputs can be collected from any othersensors and/or components, such as any or all of: the vehicle itself(e.g., from Original Equipment Manufacturer [OEM] sensors, from aspeedometer of the vehicle, from an accelerometer of the vehicle, from ascale for determining the cargo load of a truck, from a weight sensor,etc.), supplementary sensors added to (e.g., fixed to, coupled to anexterior of, etc.) the vehicle (e.g., radar sensors, lidar sensors,cameras, etc.), and/or any other suitable sensors.

In a set of specific examples, the set of inputs used to determine a setof driving events are collected only from a personal user device (e.g.,mobile phone, etc.) associated with the driver and/or a passenger of thevehicle. In another set of specific examples, the set of inputs used todetermine a set of driving events are collected only from asupplementary device, such as a 3^(rd) party device with a set ofsensors and a processing subsystem and/or computing subsystem, removablycoupled to the vehicle (e.g., removably coupled to a charging port ofthe vehicle).

Additionally or alternatively, the sensors can be from any devicesand/or combination of devices.

The system preferably includes and/or interfaces with a vehicle, whereinthe vehicle can be an automotive vehicle (e.g., a car, truck, SUV,etc.), a light electric vehicle (e.g., an electric bike, an electricscooter, an electric skateboard, any other suitable electric vehiclethat is configured to carry at least one human, etc.), an aerial vehicle(e.g., a fixed wing aircraft, a rotary wing aircraft, a drone, ahovercraft, etc.), a mass transit land vehicle (e.g., a bus, alocomotive train, a light-rail train, etc.), an aquatic vehicle (e.g., apleasure craft, a ferry, a hydrofoil craft, etc.), and/or any othersuitable vehicle. The vehicle is preferably configured to be driven by ahuman operator (e.g., under manual operation, under semi-autonomousoperation, etc.), but can additionally or alternatively be configured tobe driven under autonomous operation, and/or any combination.

The system further preferably includes and/or interface with a computingsubsystem, wherein the computing subsystem functions to perform any orall of: processing of the set of inputs; organization of the set ofinputs; implementing any or all of a model; determination of a set ofrisk scores; producing an output based on the set of risk scores; and/orcan be used to perform any other processes and/or combination ofprocesses. The computing subsystem is preferably arranged at leastpartially remotely (e.g., at a remote computing subsystem, cloudcomputing subsystem, etc.), but can additionally or alternatively bearranged locally (e.g., at an onboard computing subsystem of the userdevice, at a computing subsystem of the vehicle, etc.), and/or at anyother suitable locations. Additionally or alternatively, the computingsubsystem can be arranged at any or all of: one or more systemcomponents, remotely arranged, distributed among multiple componentsand/or remotely arranged, and/or otherwise arranged. such as an onboardcomputing subsystem of a user device in communication with a remotecomputing subsystem.

In preferred variations, a model used to determine a set of risk scoresand/or one or more outputs of the model (e.g., lookup table of riskscores, set of predetermined route segments and associated risk scores,etc.) is located (e.g., stored, referenced from, etc.) at a remotecomputing subsystem, wherein a computing subsystem of the user device isin communication with the remote computing subsystem, such that the userdevice can transmit sensor information and/or driving events (e.g.,determined at the onboard computing subsystem, determined at the remotecomputing subsystem, etc.) to the remote computing subsystem forprocessing (e.g., by the model, based on outputs of the model such as aset or risk scores, etc.). Additionally or alternatively, the modeland/or one or more model outputs can be located locally (e.g., stored ata client application, stored at a user device, etc.) and/or any othercomputing subsystems can be implemented.

The computing subsystem can include any suitable subcomponents, such asa any or all of: memory, storage, processing (e.g., CPUs, GPUs,processes, system-on-a-chip, etc.), and/or any other suitablecomponents.

Additionally or alternatively, the system can include any other suitablecomponents.

4. Method

As shown in FIG. 1, the method 100 for risk determination of a routeincludes collecting a set of inputs S110 and determining a set of riskscores S140. Additionally, the method 100 can include any or all of:processing the set of inputs S120; organizing the set of inputs S125;determining a model based on the set of inputs S130; determining a setof risk scores 140; producing an outputs based on the set of risk scoresS150; and/or any other suitable processes.

Further additionally or alternatively, the method 100 can include any orall of the methods, processes, embodiments, and/or examples described inany or all of the applications described above.

The method 100 functions to assess a risk associated with a particularroute, which can subsequently used to produce one or more outputs basedon the risk, such as, but not limited to, any or all of: an informedselection of a route by a driver; the providing of navigationinstructions which align with an optimal route in light of its risk; anotification to a driver and/or other entities related to the risk ofthe route; informed decision making by one or more entities (e.g.,insurance companies, infrastructure agencies, etc.) in light of the riskof a route; and/or the method 100 can function to produce any othersuitable outputs. Additionally or alternatively, the method 100 canfunction to produce and/or validate a model with which to determine therisk associated with a route and/or a set of route segments(equivalently referred to herein as route links and/or road links).Further additionally or alternatively, the method 100 can function toperform any other suitable functions.

The method 100 is preferably performed with a system as described above,but can additionally or alternatively be performed with any othersuitable system(s).

4.1 Method: Collecting a Set of Inputs S110

The method 100 includes collecting a set of inputs S110, which functionsto collect information with which to ultimately one or more outputsbased on a set of risk scores. Additionally or alternatively, S110 canfunction to collect information with which to determine a model and/or aset of model parameters (e.g., set of weights) used to determine the setof risk scores, collect information with which to update a model, and/orcan perform any other suitable functions.

S110 is preferably performed contemporaneously with (e.g., prior to,during, partially overlapping with, fully overlapping, after, etc.) thetraversal of a route by a driver, such as at any or all of: prior toinitiation of the route (e.g., as the driver is entering a destinationinto a navigation application, as the drive is entering the vehicle,upon initial movement of the vehicle, etc.); at initiation of the route(e.g., upon initial movement of the vehicle); while the vehicle istraversing the route; at determination of the route (e.g., untildetermining that the vehicle has ceased motion, until determining that apredetermined time has passed since the vehicle has ceased motion,etc.); and/or at any other suitable time(s). Additionally oralternatively, S110 can be performed at any other suitable time(s).

S110 is preferably performed at least once during the method 100, andadditionally or alternatively any or all of: multiple times (e.g.,continuously, at a predetermined frequency, prior to any or all of theprocesses, during any or all of the processes, after any or all of theprocesses, etc.). Further additionally or alternatively, the method 100can be performed in absence of S110.

In preferred variations in which an output is produced by a set of riskscores, S110 can be collected at any or all of these times (e.g.,depending on what output is desired). In specific examples in whichroute options are provided to a user and/or automatically selected basedon risk, S110 can, for instance, be performed prior to traversal of theroute when a user is entering a destination into a navigation clientapplication. Additionally or alternatively, S110 can be performed any orall of: throughout the traversal of the route (e.g., continuously, at apredetermined frequency, etc.), at all times (e.g., checking at apredetermined frequency to see if vehicle is moving), in response to atrigger, and/or at any other suitable times.

In preferred variations in which a model is determined for assigning arisk score to a route and/or set of route segments, inputs arepreferably collected multiple times for an aggregated set of users, suchas continuously (e.g., at a predetermined frequency) while the user isdriving and/or the vehicle is in operation.

S110 preferably includes collecting data associated with a set of routesegments, which functions to provide information with which adetermination of route risk (and/or inversely route safety) can bedetermined. Additionally or alternatively, S110 can function to provideinformation with which a determination of driver safety can bedetermined and/or produce any other suitable output(s), such as any orall of those described in subsequent processes of the method.

A route herein refers to a particular course traversed by a vehicleduring a trip, wherein a trip is preferably defined by a starting pointand an ending point (equivalently referred to herein as a destination),but can additionally or alternatively be defined in any other suitableway(s). The route can include any suitable roadways and combinations ofroadways, such as any or all of: highways, motorways, residential roads,service roads, and/or any other suitable roadways.

Each route is preferably defined by a set of route segments, which serveas “building blocks” for constructing the route traversed by the vehicleduring its trip. The route segments are preferably virtualrepresentations of a portion of a roadway, but can additionally oralternatively include one or more tangible components, such as thecorresponding portion of the roadway. The route segments are preferablydefined such that they can construct numerous possible routes throughthe modular combination of adjacent route segments, wherein any route isconstructed from a series of route segments. In some variations, forinstance, the set of possible route segments optionally includesintersections as a first subset of route segments and includes theportions of road connecting the intersections as a second subset ofroute segments. Intersections can refer to any or all of: traffic lightintersections, stop sign intersections (e.g., 2-way stops, 4-way stops,etc.), roundabouts, highway features (e.g., on ramps, off ramps,congested and/or otherwise complicated areas, etc.), intersectionsassociated with yield signs, and/or any other suitable roadinfrastructure features. In at least the second subset of road segments,the road segments can be variable in length. In some examples, forinstance, the roadway between two intersections is defined as a singleroute segment. Additionally, the first subset of route segments can bevariable in length. Additionally or alternatively, however, any or allof the route segments can be defined to be uniform or substantiallyuniform (e.g., defining a distance below a predetermined threshold,defining a distance above a predetermined threshold, defining a distancebetween a minimum threshold and a maximum threshold, etc.). Furtheradditionally or alternatively, the route segments can be otherwisedefined.

In preferred variations, for instance, a route traveled by a vehicle isdefined as a sequence of route segments, wherein each of the sequence ofroute segments is defined as at least one of: a segment of a road and anintersection. In a specific example, the set of route segments fromwhich a sequence of route segments is chosen includes a set ofintersections in a geographic region along with the sections of roadwhich connect the intersections, wherein the section of road connectingtwo intersections preferably forms a single route segment, but canadditionally or alternatively form multiple route segments. In a secondspecific example, the set of route segments from which the sequence ofroute segments is chosen includes a set of intersections along with thesections of road which connect the intersections, wherein the section ofroad connecting two intersections can form any number of route segmentssuch that each route segment is of a uniform length or a substantiallyuniform length (e.g., within a set of distance/length thresholds).Additionally or alternatively, the route segments can include only thesegments connecting intersections, only the intersections, and/or can beotherwise defined.

In a first set of variations, S110 includes collecting a set of routesegment parameters, such as route segment identifiers (route segmentIDs) and/or any other parameters associated with a particular routesegment (e.g., location(s), distance, estimated millions of milestraveled on route segment per year, etc.). In specific examples, theroute segment parameters are collected when determining the model andoptionally when determining a set of one or more outputs, which canfunction to perform any or all of: informing data organization of otherinputs (e.g., assign sensor information to the proper route segmentbased on location information collected at a user device); determine therisk associated with the route segment; and/or perform any othersuitable functions.

The route segment parameters are preferably predetermined and collectedfrom a database, such as a map database (e.g., OpenStreetMap [OSM]database, navigation/map client application database, privately owneddatabase, publicly owned and/or available database, etc.). Additionallyor alternatively, the route segment parameters can be received from anyother suitable sources, dynamically determined (e.g., during the method100, prior to the method 100, etc.), and/or otherwise determined.

At least a portion of the set of inputs includes sensor inputs collectedfrom a sensor system (e.g., from a user device, from the vehicle, etc.)such as from any or all of: a GPS sensor, accelerometer, gyroscope,magnetometer, gravitational sensor, and/or any other suitable sensors.Additionally or alternatively, any or all of the data can be collectedfrom a processing system (e.g., system on a chip, integrated circuit,CPU, etc.) of the user device, a remote computing system (e.g., cloudcomputing system), the vehicle, a clock (e.g., a real time clock [RTC]of the user device), a secondary client application (e.g., a navigationapplication, a weather application, etc.) of the user device, and/or anyother suitable information source. Additionally or alternatively, theinputs can be otherwise collected. The sensor inputs are furtherpreferably collected at a client application executing on the userdevice and/or a software development kit (SDK) associated with theclient application, but can additionally or alternatively be collectedfrom a remote computing system, remote storage, a remote set of sensors(e.g., external sensors in an environment of the vehicle), and/or at anyother suitable component(s).

As shown in FIG. 1, the sensor inputs can include any or all of:location information (e.g., latitude and longitude, GPS coordinates, aGPS trace, a partial GPS trace, a route identifier, a route segmentidentifier, an address, a vehicle pose, etc.), motion information (e.g.,acceleration information, speed and/or velocity information,position-velocity-acceleration [PVA] data, etc.), and/or orientationinformation (e.g., gyroscopic information, magnetometer information,etc.). Additionally or alternatively, the sensor information can includeany or all of: optical information (e.g., from one or more cameras, froma camera of the user device, from a camera fixed to the vehicle, from acamera in an environment of the vehicle, from a stream showing localweather conditions, from a stream showing road conditions, etc.), radarinformation, lidar information, temperature information (e.g., from atemperature sensor of the user device), humidity information (e.g., froma humidity sensor), pressure information (e.g., to detect a change ofpressure of the vehicle such as due to airbag deployment), contactinformation (e.g., from a contact sensor of the user device to detectdevice usage/handling, from an optical sensor of the user device todetect device usage/handling, etc.), proximity information (e.g., from aproximity sensor of the vehicle to detect closeness of the vehicle toanother vehicle and/or object), and/or any other suitable informationfrom any suitable sensors.

Additionally or alternatively, any other suitable inputs can becollected from any or all of: a client application, a user device, acomputing system, a database, and/or any other suitable components. Insome variations, for instance, the set of inputs can include any or allof: information associated with a user's usage of a user device (e.g.,while driving, client application usage, device handling information,etc.); historical information associated with the user (e.g., historicalroutes driven by user); vehicle information (e.g., make and model); userpreferences (e.g., maximum risk threshold, maximum extra distancewilling to be traveled for a safer route, maximum extra time willing tobe spent for a safer route, etc.); and/or any other suitable inputs.

The sensor inputs can be collected continuously (e.g., for the durationof the trip, while the vehicle is moving, while the vehicle has a speedabove a predetermined threshold, etc.), at a predetermined frequency,intermittently, in response to a trigger, and/or collected at anysuitable time(s) (e.g., as described above).

The set of inputs preferably includes location information (e.g., fromthe sensor system, from a database, from another source, etc.), such asGlobal Positioning System (GPS) information and/or GeographicInformation System (GIS) information, which functions to properly locateand assign the risk scores determined in subsequent processes of themethod. In preferred variations, for instance, sensor data is collectedfrom one or more sensors of the user device (e.g., accelerometer data,orientation data, etc.) while the vehicle is driving, location data iscollected from a GPS system (e.g., of the user device, of the vehicle,etc.) contemporaneously with the sensor data, and the sensor data andthe location data are attributed to (e.g., assigned to) roadinfrastructure (e.g., routes, roadways, intersections, etc.), such as aroute segment (e.g., predetermined route segment as described above),through GIS information and any number of GIS tools (e.g., lat-longvariable, Geo-hash, etc.). Additionally or alternatively, the locationinformation can be otherwise suitably used.

The location information can additionally include traffic and/or routeinformation, such as any or all of: a speed limit associated with theroute; road conditions associated with the route (e.g., smooth surface,potholes, clarity of lane markings such as lane lines, curvature aroundturns, etc.); a level of traffic associated with the route; a temporaryor permanent zoning associated with the route (e.g., pedestrian zone,biking zone, school zone, hospital zone, construction, residential zone,high density residential zone, etc.); infrastructure features associatedwith the route (e.g., traffic intersection with or without trafficlights, traffic intersection with or without stop signs, highway entryand/or exit ramps, etc.), and/or any other suitable information.

The location information can be any or all of: predetermined (e.g., aprescribed speed limit); dynamically determined (e.g., based oninformation collected at one or more sensors of a sensor subsystem suchas a camera); determined from an information source (e.g., internet,secondary client application, etc.); determined in any suitablecombination of these ways; and/or otherwise determined.

In some variations, the location information (e.g., traffic information)is used to determine a volume of traffic per mile associated with thetrip, wherein the volume of traffic can include a number of vehicles(e.g., surrounding the vehicle, within a predetermined radius of thevehicle, having a driver with a user device executing the clientapplication and/or SDK, etc.). Additionally or alternatively, the volumeof traffic can be determined based on a movement parameter associatedwith the vehicle (e.g., speed, acceleration, frequency of stops, etc.),and/or any other suitable parameters.

Additionally or alternatively, location information from an aggregatedset of drivers can be used when building a model (e.g., as describedbelow) to determine, for instance, any or all of: an average number ofmiles driven on a particular route segment, a most popular route segmentdriven by a user, and/or any other suitable information.

The set of inputs can optionally include driver information (e.g., adriver risk score), which functions to determine a driver behaviorassociated with each of set of drivers, further preferably the riskinessof a driver's behavior (e.g., in the form of a driver risk score),wherein the driver data can include any or all of: vehicle speed (e.g.,as compared to the speed limit of the associated route segment); vehicleacceleration (e.g., aggressive acceleration, acceleration above apredetermined threshold, etc.); abrupt changes in driving (e.g., abruptchanges in velocity, abrupt changes in direction, hard turns, etc.); adevice usage (e.g., an amount of mobile device usage while driving, atype of mobile device usage while driving, a phone call amount and/orfrequency, a texting amount and/or frequency, etc.); vehicle braking(e.g., hard braking); an incidence of collisions, an incidence ofnear-collisions, and/or any other suitable parameters. The driverinformation can additionally or alternatively be used for any or all of:adjusting a risk score of a route (e.g., to remove the effects of analways-risky driver who drives on the route, to attribute the riskinessof drivers to the routes they are currently traveling on, etc.), and/orcan be used in any other suitable ways.

The driver information can optionally include a driver risk score,wherein the risk score can be determined based on any or all of: a setof algorithms, a set of models (e.g., deep learning models, machinelearning models, neural nets, etc.), and/or any other suitableprocesses. Additionally or alternatively, determining the driverbehavior can include any or all of the methods, processes, embodiments,and examples described in U.S. application Ser. No. 15/835,284, filed 7Dec. 2017, which is incorporated herein in its entirety by thisreference.

Determining a driver behavior can optionally include distinguishing adriver from a passenger, such as through any or all of the methods,processes, embodiments, and examples described in U.S. application Ser.No. 16/022,120, filed 28 Jun. 2018, which is incorporated herein in itsentirety by this reference.

The data can optionally include temporal information, which functions todetermine the contributions that various temporal factors can have onthe rating (e.g., riskiness, safety, etc.) of a route. Additionally oralternatively, the temporal information can function to organize and/orcategorize any or all of the other data collected, such as in any or allof the processes of S125.

The temporal parameters can include, for instance, any or all of: a timeof day at which information is being collected (e.g., morning,afternoon, night, 8 am, 8:15 am, etc.), a time of year at whichinformation is being collected (e.g., particular month, particularseason, etc.), and/or any other suitable parameters, which canindividually and/or collectively function to assess the risk of a routebased on any or all of: traffic (e.g., rush hour) conditions, lightingconditions (e.g., based on time of day and/or time of year), weatherconditions (e.g., snow, sun, etc.), and/or any other suitabletemporally-related parameters.

The temporal parameters are preferably collected from a clock (e.g.,real time clock [RTC]) of a sensor system and/or the user device, butcan additionally or alternatively be collected from a remote computingsubsystem, a website, and/or any suitable information source.

In some variations, the temporal information functions to organize theother data collected in S110 in a time-slotted fashion (e.g., in15-minute time slots, in less than 15-minute time slots, in greater than15-minute time slots, etc.), wherein the time-slots of data can be usedto determine a risk score for a route according to the time of dayand/or year that the driver is taking the trip.

Additionally or alternatively, the data collected in S110 can includeenvironmental information, such as any or all of: weather (e.g., snow,rain, sleet, fog, etc.), temperature, humidity, light, and/or othersuitable information. Further additionally or alternatively, any othersuitable data can be collected in S110.

The set of inputs preferably includes inputs from a set of one or moredatabases (e.g., lookup tables), wherein the database inputs arepreferably used in building a model for determining risk scores (e.g.,as described below). Additionally or alternatively, this information canbe collected from other sources (e.g., from the sensor system inputs)and/or S110 can be performed in absence of collecting databaseinformation.

The set of databases preferably includes one or more databases whichinclude collision information associate with the regions containing theroute segments for which risk scores are determined for with a model.These can include (e.g., as shown in FIG. 7), but are not limited to,any or all of: a database indicating the number of collisions occurringin the region (e.g., in the past year, in the past 2 years, annualaverage, etc.) and the location (e.g., latitude and longitude, GPScoordinates, closest address, route segment identifier, etc.) in whichthe collision occurred; a database including an overall collisionfrequency occurring in the region (e.g., collisions per millions ofmiles) and/or an average number of total miles driven in the region byall vehicles (e.g., number of millions of miles driven annually in theregion); a database including the route segment parameters (e.g., OSMdatabase); and/or any other suitable databases.

S110 can optionally include receiving the route risk scores in S140,wherein the route risk scores are preferably determined by a model(e.g., as described below).

Additionally or alternatively, any other suitable inputs can be receivedin S110 from any suitable sources and/or combination of sources.

In a first set of variations, S110 includes collecting data from asensor system of the user device, which is subsequently used todetermine a set of driving events (e.g., driver's acceleration patterns,driver's hard braking, driver's mobile device usage and interactions,driver's speeding, and driver's dangerous turn patterns) associated withthe driver's traversal of a route and location information (e.g., GPSdata) characterizing the location of the route, which is subsequentlyused to associate the inputs with one or more routes segments.Additionally or alternatively, S110 can include collecting databaseinformation with which to determine the risk score(s) associated withone or more routes. In specific examples, the data is collected from anyor all of: a GPS sensor, an accelerometer, a gyroscope, a magnetometer,and a gravitational sensor of the user device, which can be used todetermine any or all of: a driver behavior, a route location, routefeature (e.g., traffic), and/or any other suitable information.Additionally, one or more temporal parameters can be determined and/orassociated with the data.

In specific examples, the sensor system is part of a mobile user device(e.g., smart phone) of the driver, wherein the mobile user device isarranged within the vehicle (e.g., mounted to a dashboard, in a driver'spocket, on a seat, etc.) during driving.

In additional or alternative specific examples, the sensor system ispart of a 3^(rd) party device, wherein the 3^(rd) party device isarranged within and/or coupled to the vehicle.

Additionally or alternatively, the sensor system can be otherwisedistributed among and/or arranged within components.

In a second set of variations, additional or alternative to the 1^(st),S110 includes collecting navigation information, such as a destinationof the driver, wherein the destination is used subsequently in themethod to recommend and/or select a route for the driver based on therisk scores associated with one or more potential routes which can betaken to reach the destination. Additionally or alternatively, S110 caninclude receiving dynamic navigation and/or location information withwhich to adjust navigation instructions for the driver (e.g., to adjustto a lower risk route).

In a third set of variations, additional or alternative to thosedescribed above, in which a model is subsequently determined, S110includes collecting sensor information from a set of user devicesassociated with an aggregated set of multiple drivers (e.g., drivingroutes freely), along with information from a set of collision databasesand a map database identifying a predetermined set of route segments,wherein the model is determined based on the inputs.

Additionally or alternatively, S110 can be otherwise performed.

4.2 Method: Processing the Set of Inputs S120

The method 100 includes processing the set of inputs S120, whichfunctions to interpret the set of inputs and prepare them for use indetermining the risk associated with a route and/or a model fordetermining the risk associated with a route. Additionally oralternatively, S120 can function to clean up (e.g., through signalsprocessing, noise removal, etc.) any or all of the set of inputs, fillin missing information associated with any or all of the set of inputs(e.g., a partial GPS trace), and/or perform any other suitablefunction(s).

S120 is preferably performed in response to S110, but can additionallyor alternatively be performed at any or all of: multiple timesthroughout the method (e.g., continuously, at a predetermined frequency,etc.), in response to a trigger, and/or at any other suitable times.Further additionally or alternatively, the method 100 can be performedin absence of S120.

S120 is preferably performed at a remote computing system, but canadditionally or alternatively be performed at any or all of: a userdevice (e.g., a processing system of the user device), a clientapplication executing on the user device and/or an SDK associated withthe client application, and/or any other computing systems. In preferredvariations in which a model is determined, for instance, S120 includescollecting, at a remote computing system, data from a set of multipleuser devices associated with a set of users, wherein the data is used todetermine a set of events, wherein the set of events are then associatedwith the proper route segments at which the events occurred.

S120 preferably includes determining a set of driving events based onthe set of inputs, which functions to enable risky driver behavior to bedetected and used in the determination of the route risk score(s)(and/or the determination of a model used to determine the route riskscore(s)). Additionally or alternatively, driving events can beotherwise determined, S120 can be performed in absence of determiningdriving events, and/or S120 can be otherwise suitably performed.

In some variations, for instance, determining a set of events based onthe set of inputs functions to determine actual and potentialcontributors to the relative safety of route segments, and in turn therisk associated for routes that a driver may traverse and/or istraversing.

The set of inputs used to determine the events preferably includes atleast sensor information, further preferably sensor informationcollected at one or more user devices. Additionally or alternatively,the set of events can be determined based on other sensors, other inputs(e.g., databases), and/or otherwise suitably determined.

The set of events can include actual events, predicted events, or anycombination of actual and predicted events.

The set of events can include collision events corresponding to detectedcollisions, which can be detected through any or all of the methods,processes, embodiments, and examples described in U.S. application Ser.No. 15/243,565, filed 22 Aug. 2016, which is incorporated herein in itsentirety by this reference. In variations, for instance, detecting acollision event can include extracting one or more movement featuresfrom at least one of a movement dataset and a supplementary dataset,such as from data collected in S110, wherein the movement features arepreferably associated with at least one of a position, a velocity, andan acceleration characterizing the movement of the vehicle during a timeperiod. Movement features can include any one or more of: raw movementdata (e.g., raw location data, raw motion data, etc.), processedmovement data (e.g., through a processing operation described above),movement profiles (e.g., driving profile, braking profile, positionprofile, speed profile, acceleration profile, turning profile, etc.),identified driving actions (e.g., parking, acceleration, braking, shortfollowing, lane-departure, freewheeling, U-turn, left turn, right turn,over-revving, stationary vehicle, moving vehicle, etc.), vehicle motioncharacteristics, and/or any other suitable features.

In specific examples, detecting a collision event can includecalculating a vehicle braking profile and/or stopping distance frommovement data (and/or from supplementary data). A vehicle brakingprofile can be calculated from vehicle deceleration over time. Stoppingdistance can be calculated from distance traveled between initiation ofdeceleration and a vehicle stopping.

In other specific examples, detecting a collision event can includeidentifying or estimating an acceleration feature describing changes invehicle acceleration.

In yet other specific examples, detecting a collision event can includederiving movement features from any or all of: image and/or videoanalysis of media captured by one or more cameras associated with thevehicle (e.g., mobile computing device cameras, vehicle cameras, etc.);interpreting speech recorded by microphones of the navigation device toextract driving profile features (e.g., describing driver behavior)and/or detect a sound associated with a collision (e.g., sound ofvehicle contact, sound of airbag deployment, etc.); interpreting speechbased on meaning (e.g., driver behavior can be detected based on whatpeople say) and/or emotion (e.g., driver behavior can be detected basedon identified emotions); extracting a vertical vehicular motion feature(e.g., from vertical accelerometer data) describing motion of thevehicle perpendicular a road surface; determining an accident based onradar and/or lidar information; and/or based on any other suitableinformation and processes.

The collision events can additionally or alternatively be determinedbased on other suitable inputs and/or data, such as any or all of:collision data from a news source (e.g., reporting active collisions), aGIS database, historical collision records and/or databases, and/or anyother suitable information.

In specific examples, determining collision events includes receivingcollision information and the corresponding location of each collisionfrom a collision database and optionally any other information from anydatabases and/or information sources.

The set of events further preferably includes a set of potentialcollision events (e.g., as shown in FIG. 4), equivalently referred toherein as dangerous events and/or risky events, which have a potentiallyhigh propensity for causing a collision, and can function to produce arobust method for determining collision risk in absence of a largeamount of actual collision event data, since collision events arerelatively rare (e.g., conventionally measured as a number of events permillion miles). The set of dangerous events need not result in acollision, but can instead be events which are any or all of: involvedin a significant percentage of collision events (e.g., percentage abovea predetermined threshold); involved in near-miss collision events;involved in minor collision events; involved in major collision events;are reported by a driver; and/or are otherwise classified. Additionallyor alternatively, the dangerous events can include actual collisionevents, such as those described above.

The set of potential collision events is preferably determined, at leastin part based on sensor data of the user device, further preferablysensor data described above (e.g., for determining collision events withsensor data), but can additionally or alternatively be determined basedon any suitable data and with any or all of: a set of algorithms, amodel (e.g., a deep learning model, a predictive model, etc.), patternmatching, and/or any other suitable processes. In preferred variations,the set of potential collision events are preferably determined based onsensor inputs as described above for the collision events, such asthrough any or all of the methods, processes, embodiments, and examplesdescribed in any or all of: U.S. application Ser. No. 15/243,565, filed22 Aug. 2016; U.S. application Ser. No. 16/700,991, filed 2 Dec. 2019;each which is incorporated herein in its entirety by this reference.

The set of potential collision events can include any or all of: anaggressive acceleration event (e.g., a magnitude of acceleration of thevehicle above a predetermined threshold, a frequency of accelerationabove a predetermined threshold, a duration of threshold above apredetermined threshold, etc.); a hard braking event (e.g., a magnitudeof braking above a predetermined threshold, a frequency of braking abovea predetermined threshold, a duration of braking above a predeterminedthreshold, etc.); a mobile device interaction event (e.g., a mobiledevice usage above a predetermined duration of threshold, a frequency ofdevice usage above a predetermined threshold, a duration of device usageabove a predetermined threshold, a type of device usage, a percentage oftime spent interacting with the user device above a predeterminedthreshold, etc.); a speeding event (e.g., speed above a speed limit by apredetermined threshold, a duration of speeding above a predeterminedthreshold, a frequency of speed above a predetermined threshold, etc.);a low speed event (e.g., driving substantially slower than speed limitand/or surrounding traffic, driving substantially slower than the speedlimit in absence of traffic and/or inclement weather conditions, etc.);a dangerous turn event (e.g., an unexpected turn direction); a lanechange event (e.g., sudden lane change, cutoff of another driver, etc.);a traffic violation (e.g., running a stop sign, running a stop light,etc.); tailgating; and/or any other suitable events.

S120 preferably includes associating each event with a particular routesegment at which the event occurred. Establishing this associationpreferably includes locating the event (e.g., based on locationinformation collected at a user device, based on GIS information, etc.)and assigns it to one of a predetermined set of route segments. In avariation as shown in FIG. 2, for instance, the path traversed by a userduring a trip (e.g., Route 1, Route 2, Route 3, etc.) is associated witha set of predetermined route segments (e.g., based on GIS information),wherein the grid represented in FIG. 2 includes a set of nodes (e.g.,“A”, “B”, “C”, etc. in FIG. 2), which each correspond to anintersection, and a set of edges (e.g., “S-M”, “M-G”, “G-H”, etc. inFIG. 2), which correspond to non-intersection roadways. The set ofevents that occur during these trips are then associated with the routesegment at which the event occurred.

S120 can additionally or alternatively include processing any or all ofthe inputs to determine a set of attributes, wherein the set ofattributes can be associated with any or all of: one or more collisionevents (e.g., as a tag associated with the event), one or more potentialcollision events, and/or one or more route segments. The attributes caninclude, for instance, but are not limited to, any or all of: a type ofroad (e.g., highway or not); weather conditions (e.g., raining, snowing,ice on road, inclement weather, non-inclement weather, etc.); trafficinformation and/or patterns; construction activity (e.g., from aconstruction feed); road conditions and/or features (e.g., potholes,age/wear of road, pavement vs. asphalt vs. dirt, etc.); roadarchitecture (e.g., hairpin turn); an environment of the vehicle (e.g.,urban, rural, residential, school zone, etc.); and/or any other suitableattributes. The set of attributes are preferably used to inform the riskassociated with a route (e.g., increase risk of route segments whichhave a hairpin turn), but can additionally or alternatively be used tobuild a model in S130 (e.g., to determine a set of weights determinedfor the model), organize information in S125 (e.g., to organizeinformation based on attributes), and/or be used in any other suitableway(s).

In a first set of variations, S120 includes determining a set ofcollision events based at least on a set of one or more databases anddetermining a set of risky/hazardous events (equivalently referred toherein as potential collision events) based one or more sensor inputscollected at a user device. The set of collision events can additionallyor alternatively be determined based on the one or more sensor inputscollected at a user device. Further additionally or alternatively, a setof one or more attributes can be determined and associated with theevents.

In a set of specific examples (e.g., as shown in FIG. 4), the set ofpotential collision events includes: an aggressive acceleration event, ahard braking event, optionally a phone interaction event, optionally anoverspeeding event, and a dangerous turn event.

In a second set of variations (e.g., as shown in FIG. 4, as shown inFIG. 7, etc.), a model (e.g., as described below) is determined based onthe information described in the first set of variations for a set ofaggregated users.

4.3 Method: Organizing the Set of Inputs S125

The method 100 can include organizing the inputs based on the set ofevents and the set of route segments S125, which functions to enableaggregation of data from multiple users and multiple routes, therebyenabling a geographic collision propensity to be determined and used ina model for determining risk route in S130. S125 can additionally oralternatively function to aggregate data based on one or more temporalparameters and/or one or more attributes, such as any or all of thetemporal parameters collected in S110.

S125 is preferably performed in response to S120 and with the processedset of inputs, but can additionally or alternatively be performed inresponse to S110 and/or at any or all of: multiple times throughout themethod (e.g., continuously, at a predetermined frequency, etc.), inresponse to a trigger, and/or at any other suitable times. Furtheradditionally or alternatively, the method 100 can be performed inabsence of S125.

S125 preferably includes determining (e.g., assigning) the particularroute segment (e.g., from a set of predetermined route segments) atwhich each event occurs, such that the event and its route segment canbe linked (e.g., paired, assigned, etc.). The particular route segmentis preferably identified based on location information collected inS110, such as location information collected at a sensor system of auser device. The user device is preferably the same user device whichcollects the information used to determine one or more of the set ofevents but can additionally or alternatively include any other suitablesensors and/or devices. Additionally or alternatively, the locationinformation can be predetermined, such as for collision events based ona database. Additionally or alternatively, one or more attributes can beassociated with the events and/or the route segments, and/or any othersuitable outputs can be produced in S120.

Organizing the set of inputs can include organizing the set of inputsbased on the set of events and the set of route segments, whichconceptually includes organizing the set of events into a set ofgroupings (“buckets”), such as those shown in FIGS. 3B-3F, which aredetermined based on the events and associated route segments of FIG. 3A.The events that occur during a set of multiple routes (e.g., Routes 1,2, and 3), which can be additionally associated with multiple usersand/or multiple time points, are organized and aggregated according tothe route segment linked to the event (e.g., in S120), which can bedetermined based on location information, such as location informationcollected at a sensor system as described in S110. As more and more datafrom multiple users and multiple routes comes in, the propensity forcollision of particular route segments (e.g., having a large number ofevents, having a large number of severe events, etc.) can be determinedand optionally quantified (e.g., in S140). This then forms a samplerepresentative of the overall ambient driving condition.

The set of events and route segments can additionally or alternativelybe organized based on temporal parameters and/or one or more attributes,which can function, for instance to enable risk scores to be determinedand used to produce an output in S150 which most closely match anenvironment of the driver. In some variations, for instance, the time atwhich an event occurs is organized based on the time of day at which itoccurs (e.g., in 1-hour segments, in 12-hour segments, in 3-hoursegments, etc.), such that a risk score is ultimately determined foreach route segment at each hour of the day to result in 24 differentbuckets of event—route segment pairs. Additionally or alternatively, anyother attributes (e.g., weather condition) can be used to organize theset of events.

In a first set of variations, S125 includes organizing the set ofpotential collision events and the set of collision events such that theevent is linked to the route segment and/or route segments at which itoccurs, wherein these event-segment pairs can optionally be furtherorganized based on temporal information and/or other attributes, suchthat risk scores can be tailored to particular environments (e.g., timeof day, weather conditions, etc.) which a driver may be driving in.

In specific examples, the set of events and their associated routesegments are determined based on the driving of an aggregated set ofusers along with one or more databases of collision events.

In additional or alternative examples, the events are their associatedroute segments are further organized based on which hour of the 24-hourday the event occurred in.

In a second set of variations, the potential collision events and thecollision events are collected in absence of database information.

In a third set of variations, the collision events are collected onlyfrom a set of databases, wherein the potential collision events arecollected based on sensors associated with an aggregated set of users.

Additionally or alternatively, S125 can be otherwise suitably performed.

4.4 Method: Determining a Model S130

The method 100 can include determining a model S130, wherein the modelfunctions to enable the determination of risk score associated with eachof the set of route segments (e.g., predetermined route segments,dynamically determined route segments, etc.). Additionally oralternatively, the model can function to enable the determination of therisk associated with an entire route and/or any other suitable outputs(e.g., as in S150). S130 can additionally or alternatively function toassess the risk associated with potential collision events (e.g., basedon a comparison with actual collision events/data), and/or can performany other suitable functions.

In preferred variations, the model preferably essentially enables thecorrelation of driving behavior (as represented in potential collisionevents) with real collision data, such as that in a different formatfrom a database, to enable a determination of risk associated with eachof a route segment. In specific examples, this enables the sparse actualcollision data (e.g., as there is relatively little collision data dueto their relatively infrequent occurrence) to be combined with and/orcorrelated with risky driving behavior from sensor data to enable arobust risk score to be determined for each of a set of route segments(e.g., even those not associated with a documented collision).

This can in turn enable, for instance, risky driving behavior which isfound to correlate to collisions to be flagged to one or more drivers(e.g., a driver performing the risky behavior, a driver in proximity tothe risky driver, etc.), such as through a notification (e.g., areal-time notification) and/or any of the outputs described in S150.

S130 is preferably performed in response to S125, but can additionallyor alternatively be performed in response to S120, in response to S110,prior to S110 (e.g., for producing an output in S150 based on themodel), and/or at any other suitable times. Additionally oralternatively, S130 can be performed at any or all of: multiple timesthroughout the method (e.g., continuously, at a predetermined frequency,etc.), in response to a trigger, and/or at any other suitable times.Further additionally or alternatively, the method 100 can be performedin absence of S130 (e.g., wherein a model is already determined).

The model in S130 is preferably determined based on the organized inputsdescribed in S125, but can additionally or alternatively be determinedbased on the processed inputs in S120, the inputs in S110, and/or anyother suitable information.

The model preferably outputs a risk score associated with each of theset of route segments. Additionally or alternatively, the model canoutput a risk score associated with each route. Further additionally oralternatively, the model can produce any other suitable outputs (e.g., adriver risk score) and/or any other suitable outputs.

In a preferred set of variations, the output of the model includes alookup table which includes at least the set of predetermined routesegments (e.g., in a first column) and a risk score (e.g., single riskscore, scalar risk score, vector or risk scores associated with eachpotential event, etc.) associated with each route segment. The table canadditionally or alternatively be divided among different hours of theday and/or other attributes (e.g., table for each hour of the day andeach type of weather). Further additionally or alternatively, the modelcan include any other suitable outputs, such as an algorithm, decisiontree, other table, and/or any other outputs.

The model is preferably determined and used to determine the outputs atleast once (e.g., wherein the risk scores output by the model are usedin each instance of S140 and/or S150). Additionally or alternatively, amodel can be determined and/or updated multiple times (e.g., at apredetermined frequency, in response to new data being collected inS110, in response to new database information being collected, etc.).

In some variations, for instance, a set of risk scores is determinedbased on the model and data from a first aggregated set of drivers(equivalently referred to herein as users), wherein the risk scores areused for a second set of users (e.g., in the outputs of S150), whereindata associated with the second set of users is also collected and usedto update the model, thereby producing an updated set of risk scores.

The model can include a single model and/or multiple models.

The model preferably includes a statistical model, wherein thestatistical model functions to determine, as an output, a risk scoreassociated with each route segment based on event data including bothactual collision events (e.g., collected from a database and/or a sensorsystem) and potential collision events (e.g., collected from a databaseand/or a sensor system). The statistical model is preferably ageneralized linear model (e.g., with a Poisson regression) but canadditionally or alternatively include any or all of: another linearmodel, a non-linear model, a Bayesian approach, a least squares fit,and/or any other statistical and/or probabilistic models.

Additionally or alternatively, the model can include a machine learningmodel (e.g., deep learning model, neural network, CNN, RNN, etc.), oneor more algorithms and/or equations, decision trees, and/or any othersuitable models.

In a first set of variations, the model includes a statistical model,wherein the risk scores are determined by the model and based on a setof model inputs including: a set of potential collision events and theirassociated route segments, a set of collision events and theirassociated route segments, and optionally one or more collision and/ortraffic parameters/statistics (e.g., from a database, from sensorinformation, etc.) associated with the region in which data is beingcollected. These parameters/statistics can optionally be used forinstance, to enable a comparison and/or a correlation between eventsdetermined with a sensor system and those from a database. In specificexamples (e.g., as shown in FIG. 7), these can include any or all of: adistance traveled per each particular route segment relative to allroute segments (e.g., based on information collected at user devices, toenable a determination of an estimated collision frequency per routesegment, etc.); an overall number of miles traveled in a region; anoverall collision frequency (e.g., collisions per million miles) in aregion; and/or any other suitable information.

In a second set of variations, the model includes one or more machinelearning models trained based on any or all of: the event data, databasedata, and/or simulated data, wherein the machine learning modeldetermines a predicted set of risk scores for a route and/or routesegment.

In a third set of variations, the model includes a combination ofstatistical and machine learning models.

4.5 Method: Determining a Set of Risk Scores S140

The method 100 includes determining a set of risk scores S140, whichfunctions to assess (e.g., quantify, rank, etc.) the propensity for risk(e.g., collision, potential collision, dangerous events, stressfuldriving conditions, etc.) associated with each of a set of routesegments and subsequently any routes composed of these route segments,such as a route that a driver may plan to take.

S140 is preferably performed in response to S130 and S125, wherein themodel in S130 is used to determine a set of risk scores, which can beused to assess an overall risk for a driver and/or other user (e.g., inlight of particular route the vehicle is going to take, in light of allroutes the driver has taken, etc.). S140 can additionally oralternatively be preferably performed in response to S110, S120, and/orcan be performed at any or all of: multiple times throughout the method(e.g., continuously, at a predetermined frequency, etc.), in response toa trigger, and/or at any other suitable times. Further additionally oralternatively, the method 100 can be performed in absence of S140.

The set of scores preferably includes a set of segment risk scores, eachof which quantifies the risk of a collision (e.g., of a route segment,or a route, etc.) on a particular route segment. Additionally any or allof a risk score (e.g., an entry in a risk score vector) can quantify thelikelihood of encountering a driver exhibiting a particularly riskydriving behavior (e.g., hard braking, aggressive acceleration, etc.),such as any or all of the potential collision events described in S120.Further additionally or alternatively, S140 can include determine aroute risk score (e.g., as described below in aggregating risk scores),a driver risk score (e.g., based on the routes taken by the driver), aregional risk score (e.g., based on the routes in the region), and/orany other risk scores.

A segment risk score is preferably determined for each route segment,which can then be used (e.g., aggregated, added together, combinedaccording to an algorithm and/or function, etc.) to determine a riskscore associated with a route made up of a set of route segments. A riskscore preferably indicates a high propensity for collision, but canadditionally or alternatively indicate a high propensity for riskybehavior, be unrelated to collision, and/or indicate any other suitableinformation. The segment risk score is preferably produced as an outputof the model in S130 but can additionally or alternatively be otherwiseproduced.

The risk score can optionally include and/or be determined based on aset of sub-scores (e.g., corresponding to the risk of each of the set ofevents, as entries in a segment risk score vector, etc.), which canfunction, for instance, to enable discretion (e.g., filtering) based ona particular driving event (e.g., according to a user's preference). Insome variations, for instance, in recommending a route to a user (e.g.,in S150), the user can view and/or adjust the options based on theuser's particular priorities and preferences. In specific examples, forinstance, a user can prioritize minimizing any or all of the followingwhen choosing a route: a level of driver aggression; a level ofdistracted drivers; stop-and-go traffic; and/or any other suitableparameters corresponding to the driving events described above and/orindependent of the driving events above.

In determining a risk score based on a set of sub-scores (e.g., drivingevent sub-scores), the sub-scores can be combined in any suitable way,such as any or all of: added together; added in a weighted fashion, suchas based on a severity of an event type (e.g., assigning a heavierweight to collision events versus dangerous events) and/or a likelihoodof an event type; combining the sub-scores according to any number ofalgorithms and models (e.g., deep learning models); and/or otherwisecombing the set of sub-scores.

Any or all of the risk scores can optionally be determined and/oradjusted based on driver-specific information and/or any other suitableparameters (e.g., current driving conditions, current sensorinformation, etc.). In some variations, the risk score associated with asegment and/or route can be adjusted and/or tailored based on driverpreferences and/or historical information. In specific examples, forinstance, for a driver who has a tendency to do hard braking, whichcould be especially risky in route segments with a high incidence ofoverspeeding (e.g., could cause a speeding tailgating vehicle to rearend the described vehicle when it brakes suddenly), the risk scoreassociated with a segment associated with high incidence of overspeeding(e.g., driving over the speed limit, driving over the speed limit by apredetermined threshold, exceeding the speed limit by at least 5miles/hour, exceeding the speed limit by at least 10 miles/hour,exceeding the speed limit by a threshold between 10 miles/hour and 30miles/hour, exceeding the speed limit by at least 15 miles/hour,exceeding the speed limit by at least 20 miles/hour, exceeding the speedlimit by at least 30 miles/hour, etc.) can be inflated for theparticular driver.

Additionally or alternatively, the risk score can be otherwisedetermined.

S140 can optionally include validating a risk score and/or the processes(e.g., algorithms, models, etc.) involved in determining the safetyscore. In some variations, S140 accounts for a potentially low amount ofdata collected for collision events and/or dangerous events byaggregating drivers into ranges based on their driver behavior (e.g., adriver behavior score) and comparing a driving event rate aggregated forthe set of drivers in the range. This can function to validate thesafety score and its efficacy as a predictor of collision if it isdetermined, for instance, that an aggregated set of drivers associatedwith risky driver behavior experiences a higher collision rate than anaggregated set of drivers associated with less risky driver behavior.Additionally or alternatively, events associated with a secondaggregated set of drivers can be used to validate the risk scores, themodel itself can go through one or more validation processes, and/orvalidation can be otherwise optionally performed.

S140 can optionally include aggregating a set of segment risk scores todetermine a route risk score. Aggregating the segment risk scores caninclude any or all of: summing scores (e.g., segment scores, normalizedsegment scores, etc.), averaging scores, determining a median score,selecting the highest segment risk score, adding in a weighted fashion(e.g., wherein the set of weights take into account a distance and/orother parameter of the segment), and/or otherwise combining the segmentscores.

In some variations, a risk score for a route is determined by addingtogether the segment risk scores for the series of segments making upthe route.

Additionally or alternatively, S140 can include any other suitableprocesses performed in any suitable order.

In a first set of variations, S140 includes calculating a segment riskscore for each of a set of route segments with a model, wherein thesegment risk scores can be aggregated together to determine the riskassociated with any route.

In a second set of variations, S140 includes calculating a risk scorefor each of a set of potential routes, wherein calculating a safetyscore for the route includes calculating a safety score for each routesegment of the route, wherein the safety score for each route segment isdetermined based on an aggressive acceleration sub-score, a hard brakingsub-score, a phone use sub-score, a speeding sub-score, and a hard turnsub-score, and wherein the safety scores for each route segment areadded together to determine the route safety score.

Additionally or alternatively, S140 can be otherwise suitably performed.

4.6 Method: Producing an Output Based on the Set of Risk Scores S150

The method 100 can optionally include producing an output based on theset of risk scores S150, which can function to perform any or all of:recommending a route to a driver; recommending an action associated witha route (e.g., while the driver is traversing the route); identifyingand surfacing risky driving behavior; advising a driver on areas ofimprovement; recommending infrastructure changes; informing an insurancecompany and/or other entity of route and/or driver riskiness; and/orperforming any other suitable function(s).

S120 is preferably performed in response to 140, but can additionally oralternatively be performed in response to S130, S125, S120, S110, and/orat any or all of: multiple times throughout the method (e.g.,continuously, at a predetermined frequency, etc.), in response to atrigger, and/or at any other suitable times. Further additionally oralternatively, the method 100 can be performed in absence of S150.

S150 can include recommending a route to a driver based on the riskscore(s) determined in S140. Recommending a route to a driver canoptionally include recommending a route prior to the driver starting atrip, wherein the route is determined based on a user's starting point,destination, the risk score and/or a driver score, and optionally one ormore driver preferences (e.g., aversion to driving routes that areassociated with a high level of driver aggression, percentage increasein distance willing to be traveled for a less risky route, percentageincrease in time willing to be spent for a less risky route, etc.).Additionally or alternatively, a route can be recommended while the useris driving, such as in an instance that a detour to the current route ispreferable (e.g., based on a dynamically updated safety score, based ona change in user preference, based on a change in traffic, etc.), basedon an input from the user (e.g., change in destination, prioritizationof time to destination instead of safety, etc.), and/or recommended atany other suitable times.

Additionally or alternatively, S150 can include recommending an actionassociated with a route, such as any or all of: dynamically changingnavigation to a less risky route, changing lanes, taking a detour (e.g.,if a safety score drops below a predetermined threshold), pulling off ofa roadway, advising the driver on an optimal time of day to take thetrip, and/or any other suitable actions.

Further additionally or alternatively, S150 can include identifying andoptionally alerting the driver to various information, such as any orall of: collision-prone zones; a collision risk parameter (e.g.,probability of collision per mile, probability of collision per route,etc.) and/or a visual indication (e.g., on a collision heat map); arisky behavior associated with the driver (e.g., distraction level abovea predetermined threshold, increasing aggression level, etc.); riskybehavior associated with the driver of a nearby vehicle; an improvementarea and/or associated tips for the driver; and/or any other suitableinformation.

Further additionally or alternatively, S150 can include recommendingand/or advising on infrastructure changes and/or policy changes based ona risk score associated with actual or proposed infrastructure features.In some variations, for instance, S150 includes advising individuals orgroups (e.g., road safety policymakers, urban/state/federal levelgroups, etc.) on the risk associated with various features and/orchanges, such as any or all of: widening lanes of a roadway, introducingmedians, changing a 4-way stop into a roundabout, adding a lane to ahighway, introducing a left turn lane to an intersection, changing speedlimits, and/or any other suitable infrastructure.

Further additionally or alternatively, S150 can include producing and/orpresenting a visual output, such as any or all of: a visualization of ascore (e.g., to be displayed at a client application), such as a safetyscore of a route (e.g., as shown in FIG. 6) and/or a score associatedwith a driver (e.g., as shown in FIG. 5); a heat map showing areasassociated with high propensity for collision; and/or any other suitablevisualizations.

Further additionally or alternatively, S150 can include informing one ormore entities of risk scores. In some variations, for instance, S150 canassess risk for individual drivers, regions, groups of drivers, driversas a whole, and/or any other groupings, which can enable an insurancecompany to determine and/or adjust insurance rates accordingly. Inspecific examples, an insurance company can assess risk and/or changesin risk associated with a driver (e.g., moves to new area with riskierroutes, starts taking different routes, historical routes taken, etc.)such that the insurance company can determine his or her insurance rateaccordingly.

Further additionally or alternatively, S150 can produce one or morefleet management outputs, such as a change in routes assigned to one ormore vehicles (e.g., trucks, autonomous vehicles) in the fleet based onthe route risks.

4.7 Method: Variations

In one variation (e.g., as shown in FIG. 8), the method 100 includes:collecting data from a sensor system of a user device, which is used todetermine a driver's behavior (e.g., driver's acceleration patterns,driver's hard braking, driver's mobile device usage and interactions,driver's speeding, and driver's dangerous turn patterns) associated withthe driver's traversal of a route and location information (e.g., GPSdata) characterizing the location of the route; linking the data withroad infrastructure (e.g., routes, roadways, intersections, etc.)through GIS information and any number of GIS tools (e.g., lat-longvariable, Geo-hash, etc.); collecting database information associatedwith actual collision events and their locations; determining a set ofevents such as any or all of a collision event and a set of potentialcollision events (e.g., an aggressive acceleration event, a hard brakingevent, a mobile device usage event, a speeding/overspeeding event, adangerous turn event, etc.); organizing data from multiple drivers andmultiple routes to produce, with a model, an aggregated assessment ofthe risk at each of a set of route segments; determining one or morescores (e.g., risk scores) associated with each of the set of routesegments and/or a set of routes composed of the route segments; andproducing an output (e.g., recommending a route) based on the scores.

In specific examples, the set of potential collision events isdetermined based on inputs collected from a set of sensor systems (e.g.,of user devices, of mobile devices, etc.) of an aggregated set of users,and the set of collision events is determined from one or both of theinputs collected from the set of sensor systems and a set of databaseinformation.

In a second variation, additional or alternative to the first, themethod 100 includes determining a model for determining a set of riskscores, wherein determining the model comprises: collecting data from asensor system of a user device, which is used to determine a driver'sbehavior (e.g., driver's acceleration patterns, driver's hard braking,driver's mobile device usage and interactions, driver's speeding, anddriver's dangerous turn patterns) associated with the driver's traversalof a route and location information (e.g., GPS data) characterizing thelocation of the route; linking the data with road infrastructure (e.g.,routes, roadways, intersections, etc.) through GIS information and anynumber of GIS tools (e.g., lat-long variable, Geo-hash, etc.);collecting database information associated with actual collision eventsand their locations; determining a set of events such as any or all of acollision event and a set of potential collision events (e.g., anaggressive acceleration event, a hard braking event, a mobile deviceusage event, a speeding/overspeeding event, a dangerous turn event,etc.); organizing data from multiple drivers and multiple routes toproduce, with a model, an aggregated assessment of the risk at each of aset of route segments; determining one or more scores (e.g., riskscores) associated with each of the set of route segments and/or a setof routes composed of the route segments.

In specific examples, the model is a statistical model such as ageneralized linear models.

In additional or alternative specific examples, the model is a machinelearning model.

In a third variation, additional or alternative to the first and second,the method includes: collecting data from a sensor system of a userdevice, which is used to determine a driver's behavior (e.g., driver'sacceleration patterns, driver's hard braking, driver's mobile deviceusage and interactions, driver's speeding, and driver's dangerous turnpatterns) associated with the driver's traversal of a route and locationinformation (e.g., GPS data) characterizing the location of the route;linking the data with road infrastructure (e.g., routes, roadways,intersections, etc.) through GIS information and any number of GIS tools(e.g., lat-long variable, Geo-hash, etc.); collecting databaseinformation associated with actual collision events and their locations;determining a set of events such as any or all of a collision event anda set of potential collision events (e.g., an aggressive accelerationevent, a hard braking event, a mobile device usage event, aspeeding/overspeeding event, a dangerous turn event, etc.); organizingdata from multiple drivers and multiple routes to produce, with a model,an aggregated assessment of the risk at each of a set of route segments;determining one or more scores (e.g., risk scores) associated with eachof the set of route segments and/or a set of routes composed of theroute segments; producing an output (e.g., recommending a route) basedon the scores; collecting the information as described above as the usertraverses a route; and updating the model based on the updatedinformation.

Additionally or alternatively, the method 100 can include producing anyother suitable outputs and/or any other suitable processes.

Although omitted for conciseness, the preferred embodiments includeevery combination and permutation of the various system components andthe various method processes, wherein the method processes can beperformed in any suitable order, sequentially or concurrently.

As a person skilled in the art will recognize from the previous detaileddescription and from the figures and claims, modifications and changescan be made to the preferred embodiments of the invention withoutdeparting from the scope of this invention defined in the followingclaims.

We claim:
 1. A method comprising: receiving motion information from aset of mobile user devices, the motion information comprising locationdata and device handling information; determining a set of near-missevents based on the motion information; determining a set of collisionevents for each of a first and second series of route segments; and witha model, determining a segment risk score for each of the first andsecond series of route segments based on the set of near-miss events andthe set of collision events; aggregating the segment risk scores of thefirst and second series of route segments to determine a first andsecond route risk score, respectively; selecting a route based on thefirst and second route risk scores; and providing navigationinstructions at a second set of mobile user devices based on the route.2. The method of claim 1, further comprising: updating the motioninformation based on positional information collected with the mobileuser device during a traversal of the route, wherein a mobile userdevice of the set comprises an inertial sensor, wherein the methodfurther comprises transforming a set of inertial measurements of theinertial sensor into the positional information.
 3. The method of claim2, further comprising: updating the model based on the updated motioninformation.
 4. The method of claim 1, wherein each of the segment riskscores is further determined based on a time of day.
 5. The method ofclaim 1, further comprising: transmitting the first route risk score toan insurance entity, wherein the first route risk score corresponds tothe route.
 6. The method of claim 1, wherein the set of near-miss eventscomprises a near-miss event associated with satisfaction of anacceleration threshold.
 7. The method of claim 6, wherein the near-missevent is further associated with mobile device usage within a thresholdtime of the satisfaction of the acceleration threshold.
 8. The method ofclaim 1, wherein the location data comprises incomplete GlobalPositioning System (GPS) traces of historical driving routes traversedby mobile devices of the set of mobile devices.
 9. The method of claim1, wherein the set of collision events is determined based on vehiclemovement features extracted from the motion information.
 10. The methodof claim 1, wherein the first set of mobile user devices comprises thesecond set of mobile user devices.
 11. A method comprising: determininga motion dataset with a mobile user device, the motion datasetcomprising: an inertial dataset and a location dataset; based on themotion dataset, determining vehicle movement features and mobile devicemotion features comprising device handling information; with a model,based on the vehicle movement features and the mobile device motionfeatures, determining a set of near-collision events; for each of aseries of route segments along a vehicle route, determining a segmentrisk score based on the set of near-collision events; and aggregatingthe series of segment risk scores to determine a route risk score. 12.The method of claim 11, further comprising transmitting the route riskscore to an insurance entity.
 13. The method of claim 11, wherein thelocation dataset comprises an incomplete Global Positioning System (GPS)trace along the vehicle route.
 14. The method of claim 11, wherein theset of near-collision events comprises a near-collision event associatedwith satisfaction of an acceleration threshold.
 15. The method of claim11, wherein the determination of the set of near-collision events withthe model occurs locally at the first mobile user device.
 16. The methodof claim 11, wherein the model comprises a statistical model.
 17. Themethod of claim 11, wherein the model comprises a convolutional neuralnetwork.
 18. The method of claim 11, further comprising: at a secondmobile user device, triggering an action based on the route risk score.19. The method of claim 18, wherein the second mobile user device is thefirst mobile user device.
 20. The method of claim 11, further comprisingtriggering an action at a remote processor based on the route riskscore.